home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / rdisc / 90may.min < prev    next >
Text File  |  1993-02-17  |  11KB  |  298 lines
  1.  
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by Steve Deering/Stanford
  6.  
  7. Minutes:
  8.  
  9. This was the third meeting of the Router Discovery Working Group.
  10.  
  11. Steve Deering started by apologizing for not having produced a draft
  12. specification of the proposed router discovery protocol in time for this
  13. meeting, and promised to do so before the July IETF meeting.
  14.  
  15. He then reviewed the current proposal, for the sake of newcomers.
  16.  
  17. The router discovery protocol uses a pair of new ICMP messages:
  18.  
  19.  
  20.    o Router Advertisement messages, which are periodically multicast by
  21.      routers.
  22.    o Router Solicitation messages, which may be multicast by hosts at
  23.      start-up time only, to solicit immediate Router Advertisements
  24.      instead of waiting for the periodic ones.
  25.  
  26.  
  27. (These were formerly called ``Router Report'' and ``Router Query''
  28. messages, respectively.)
  29.  
  30. Advertisements are sent to the ``all-hosts'' IP multicast address, and
  31. solicitations are sent to the ``all-routers'' IP multicast address.
  32. Hosts and/or routers may be configured to use IP broadcast addresses
  33. instead, though this is discouraged.  The router discovery protocol is
  34. not applicable to networks that do not support either IP multicast or IP
  35. broadcast.
  36.  
  37.  
  38.  
  39.                                    1
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46. The format of the Router Advertisement message is as follows:
  47.  
  48.  
  49.  
  50.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  51.   |     Type      |     Code      |           Checksum            |
  52.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  53.   |   Reserved    |     Count     |         Holding Time          |
  54.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  55.   |                       Router Address                        |
  56.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  57.   |                      Preference Level                       |
  58.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  59.   |                       Router Address                        |
  60.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  61.   |                      Preference Level                       |
  62.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  63.   |                              .                              |
  64.   |                              .                              |
  65.   |                              .                              |
  66.  
  67.  
  68.  
  69. Type                identifies this as an ICMP Router Advertisement.
  70.  
  71. Checksum            standard ICMP checksum.
  72.  
  73. Code and Reserved   zero.
  74.  
  75. Count               number of (Router Address, Preference Level) pairs
  76.                     included in the message.
  77.  
  78. Holding Time        number of seconds that hosts should consider the
  79.                     information in this message to be valid.
  80.  
  81. Router Address      one of the sending router's IP addresses on the
  82.                     physical network on which this message is sent.
  83.  
  84. Preference Level    preferability of the preceding router address as a
  85.                     default router address, relative to other router
  86.                     addresses belonging to the same IP subnet.
  87.  
  88.  
  89.  
  90. The usual case in which a router has more than one address on a single
  91. physical network is when that network is supporting more than one IP
  92. subnet.  A receiving host is expected to ignore those (Router Address,
  93. Preference Level) pairs that do not belong to the same IP subnet as the
  94.  
  95.                                    2
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102. host.  (This implies that a host must know its own IP address and subnet
  103. mask before it may use the information in a Router Advertisement
  104. message.)
  105.  
  106.  
  107.  
  108.                                    3
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115. The format of the Router Solicitation message is as follows:
  116.  
  117.  
  118.  
  119.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  120.   |     Type      |     Code      |           Checksum            |
  121.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  122.   |                          Reserved                           |
  123.   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  124.  
  125.  
  126.  
  127. Type                identifies this as an ICMP Router Solicitation.
  128.  
  129. Checksum            standard ICMP checksum.
  130.  
  131. Code and Reserved   zero.
  132.  
  133.  
  134.  
  135. The group then discussed a number of topics that had been raised on the
  136. mailing list since the previous meeting.
  137.  
  138.  
  139.    o Preference Level field
  140.      Deering tried again to convince the group that the Preference Level
  141.      field was unnecessary and undesirable, and again he failed.  It was
  142.      agreed that the field shall be present in the Router Advertisement
  143.      messages, if for no other reason than that the Host Requirements
  144.      document requires a preference level to be associated with each
  145.      default router (even though it does not require hosts to do
  146.      anything with it).
  147.      Deering then proposed that the Preference Level be encoded as a
  148.      signed, 32-bit, twos-complement integer, such that a higher value
  149.      means more preferable.  A router that is not configured with a
  150.      specific preference level (or that does not compute its own
  151.      preference level, based on routing information), will advertise a
  152.      level of 0.  The minimum level (80000000 hex) is reserved to
  153.      indicate routers that must not be used as default routers (i.e.,
  154.      that may be used only for specific destinations, of which the hosts
  155.      have been informed by ICMP Redirect or static configuration).
  156.      Greg Satz had proposed that a router's preference level be derived
  157.      from that router's metric for its ``default'' route, rather than
  158.      from manual configuration.  After some discussion of the merits and
  159.      weaknesses of that approach, it was agreed that it would be allowed
  160.      but not required by the router discovery specification.  It was
  161.      noted that a routing metric will normally have to be converted to a
  162.      preference level, rather than being used directly, since for most
  163.      routing metrics, smaller values mean more preferable.
  164.  
  165.                                    4
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.   No objections were raised to Deering's proposed encoding for the
  173.   Preference Level field.
  174. o multicast vs.  unicast replies to Solicitations
  175. o dallying
  176.   Two unresolved issues were:  should Advertisements sent in response
  177.   to Solicitations be multicast or unicast, and should randomized
  178.   delays be required before Solicitations and/or before responding
  179.   Advertisements?  Some people felt that dallying before
  180.   Solicitations was important to prevent massive collisions when a
  181.   LANful of hosts all boot at once, for example, after power is
  182.   switched on (in a classroom, say) or is restored after a power
  183.   failure.  After much debate, it was agreed that hosts should dally
  184.   for a short, random interval (between 0 and 1 seconds was
  185.   suggested) before sending a Solicitation.  If a host receives an
  186.   Advertisement while dallying, it should refrain from sending a
  187.   Solicitation.
  188.   The optimal router behavior in response to a Solicitation is not at
  189.   all clear -- a case was made for dallying or not, and for either
  190.   unicast or multicast responses.  Therefore, this will be left to
  191.   the implementors' discretion for now, with a suggestion that the
  192.   behavior be configurable.  The group would welcome any analysis,
  193.   simulation results, or reports of field experience that might favor
  194.   a particular behavior.
  195. o periodic advertising rate
  196.   Another outstanding issue was how often the periodic, unsolicited
  197.   Advertisements should be sent.  The choice depends on whether or
  198.   not the advertisements are being used for black-hole detection, in
  199.   addition to simple router discovery.  For black-hole detection, the
  200.   advertising rate must be high enough to allow router failures to be
  201.   detected before transport connections fail (an interval of 10
  202.   seconds is the value used for this purpose in the ISO ES-IS
  203.   protocol).  If the advertisements are only used for router
  204.   discovery, a much longer interval (10 minutes, say) would be
  205.   adequate -- in this case the periodic advertisements serve only for
  206.   recovery from the situation in which hosts and routers boot up on
  207.   different sides of a subnet partition, which is later healed.
  208.   In the absence of agreement on how black-hole detection should be
  209.   done, the advertising interval must be configurable.  The initial
  210.   version of the document will suggest a default interval of 10
  211.   minutes.  Subsequent decisions on black-hole detection may cause a
  212.   smaller default value to be recommended.
  213. o black-hole detection
  214.   Once the router discovery specification has been agreed upon, it
  215.   has been suggested that this working group might turn its attention
  216.   to the black-hole detection problem.  A general discussion of the
  217.   problems and possible solutions ensued, with no agreements being
  218.   reached.  (It was pretty much a rehash of previous discussions on
  219.   the group mailing list; an archive of those messages is available
  220.   for the interested reader.)
  221.  
  222.  
  223.  
  224.                                 5
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231. Action Items
  232.  
  233.  
  234.    o Deering to generate a draft Router Discovery specification before
  235.      the July IETF meeting.
  236.    o Experimental implementations of the proposed protocol to be
  237.      developed and deployed -- no promises, but Andrew Cherenson and
  238.      John Veizades both offered to help (presumably for Unix and for the
  239.      Macintosh OS, respectively), as soon as Deering gets the
  240.      specification done.  Greg Satz has previously offered the source
  241.      code for his BSD Unix implementation of cisco's Gateway Discovery
  242.      Protocol (GDP) as one possible starting point.
  243.  
  244.  
  245. Next Meeting
  246.  
  247. The Router Discovery Working Group will next meet in Vancouver, at the
  248. July/August IETF meeting.
  249.  
  250.  
  251.  
  252.                                    6
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259. ATTENDEES
  260.  
  261.  
  262.     Pat Barron               pat@transarc.com
  263.     Fred Bohle               fab@saturn.acc.com
  264.     Steven Bruniges
  265.     David Burdelski          daveb@ftp.com
  266.     Duane Butler             dmb@network.com
  267.     John Cavanaugh           J.Cavanaugh@StPaul.NCR.COM
  268.     Andrew Cherenson         arc@sgi.com
  269.     Noel Chiappa             jnc@PTT.LCS.MIT.EDU
  270.     Steve Deering            deering@pescadero.stanford.edu
  271.     Dave Forster
  272.     Richard Fox              sytek!rfox@sun.com
  273.     Karen Frisa              karen@kinetics.com
  274.     Steve Hubert             hubert@cac.washington.edu
  275.     Van Jacobson             van@helios.ee.lbl.gov
  276.     Stev Knowles             stev@ftp.com
  277.     Yoni Malachi             yoni@cs.stanford.edu
  278.     Keith McCloghrie         sytek!kzm@hplabs.HP.COM
  279.     Leo J. McLauglin III     ljm@twg.com
  280.     Jeff Mogul               mogul@decwrl.dec.com
  281.     John Moy                 jmoy@proteon.com
  282.     Mike Patton              MAP@LCS.MIT.EDU
  283.     Drew Perkins             ddp@andrew.cmu.edu
  284.     Stephanie Price          cmcvax!price@hub.ucsb.edu
  285.     Michael Reilly           reilly@nsl.dec.com
  286.     Greg Staz                satz@cisco.com
  287.     Tim Seaver               tas@mcnc.org
  288.     Frank Slaughter          fgs@shiva.com
  289.     Richard Smith            smiddy@pluto.dss.com
  290.     Brad Strand              bstrand@cray.com
  291.     Cal Thixton              cthixton@next.com
  292.     John Veizades            veizades@apple.com
  293.     Jonathan Wenocur         jhw@shiva.com
  294.  
  295.  
  296.  
  297.                                    7
  298.